A Perspective On Open Process Specification

It is the job of the Process Design Kit (PDK) engineers to deliver a high-quality PDK that properly represents the process requirements and constraints and supports the design flows used by their customers. The PDK engineer takes multiple inputs describing the process and the devices and circuitry in the process and generates the output in the form of OpenAccess technology libraries (techDB), design parameter definitions, pcells, verification decks, models and other code which describe the process to the design tools in the flow. To the end user, the resulting PDK should operate seamlessly within their chosen flow. To that end, the PDK engineers must thoroughly test the pcells and PDK to make sure it models the process accurately.

The different levels of PDK development requirements are determined by the PDK supplier. The Fab PDK engineer must supply a PDK that works across the largest variety of design tools, supporting the internal design flows, the tools used in with large user bases and new and existing design tools which aid their customers to create designs the fab can manufacture. The company-wide CAD group focuses on support of the design flows being used internally, supporting design flows specific for their product array. They may replace or supplement a Fab supplied PDK. The design group may develop specialized devices and add some design specific constraints, but is focused on the much smaller set of tools and solving chip specific design problems.

PDK generation starts with process capture. The process engineers determine the process’s materials and specifications: names, thickness, resistance, etc. They also develop the initial set of process constraints and rules that improve manufacturability. These values are often recorded using spreadsheets and other documents that are captured in the process documentation repository (DRM), an expanded version of what was once an eight-page design rule manual. The newer processes require an overwhelming amount of data. The circuit designers create the initial test devices, developing topological, electrical, logical and simulation models of the primitives such as an nmos. These models are based on the measurements and constraints supplied by the process engineers. Various analysis tools capture this data, which must be input to the DRM. The DRM handoff to the PDK developers often requires the data to be recaptured for the PDK generation system. There are many different inputs from diverse engineering groups using a variety of tools that have to be resolved into data dictionaries understood by the PDK generation system.

The resolved PDK data, including layer and rule definitions, is now in formats that are used as input to the PDK generation system. The handoff is dictated by the compatibility of the data format, how a PDK capture tool defines a layer has to be understood by its comparable PDK layer generation tool to create the data correctly in the techDB. This data may be in a variety of data formats, each of which requires a reader/writer or the internal PDK documentation format into which all tools must be taught to read and write. These proprietary data and methods limit the ability for the PDK capture engineers and the PDK generation engineers to choose the best tools for their step in the process. Without a standard communicating the PDK data, it is hard to design a new tool or a new flow into either toolset. Commercial solutions are excluded or of limited usability.

PDK quality is assured by using good developmental practices and intensive testing. The decks must be checked against documented process constraints, the models and pcells exercised and the results validated. The devices have to be run through the proposed flows to ensure that they do work properly. Current testing practices consist mainly of home grown frameworks from Open Source and internal development. Some vendor support is available for a limited subset of the testing requirements but the lack of standards requires individualized solutions. Quality varies, from a low of requiring the user to create their own replacement PDK’s to the high quality of PDK’s that work in the flow as soon as they are installed. Test data are currently separate from the PDK definition and user solutions, good or bad, predominate.

The Pcell generation sub flow shows just a piece the whole PDK generation work flow. Each tool in that flow must know how to read the data in the user formats. There is no connection between the captured process data and the testing toolsets.

 
Open Process Specification
The Open Process Specification (OPS), an Si2 standard first released in January of 2013, is designed to standardize the data that describes the process, creating a standard definition for process objects such as layers and constraints as well as design objects such as devices, parameters and layer processing. The SI2 OpenPDK Coalition standards are mainly XML descriptions created by working groups and enforced by OPS XSD standards.

Gilles Namur of STMicroelectronics chairs the OPS working group. The current specifications were created by working groups composed of members including design groups, CAD and PDK engineers, and EDA vendors. Early efforts standardized the parameter definition and representation, the Design Data Format (DDF) by a working group (WG), co-chaired by Li-Chien Ting (Cadence) and myself, as well as the primitive symbol library, WG led by Rich Morse (Synopsys). The tool interface (TI) WG was led by Mohamed Youssef (Mentor Graphics) and standardizes the interface between the DDF for a device and various tools including netlisters and simulators. The Universal Layer Model WG, led by Jake Buurma (Si2), standardized definitions and operations on layers for OPS. I have to mention Sue Strang (IBM), who has been instrumental in the definition of multiple standards and all those who contribute or have contributed to the OpenPDK working groups.

The OPS now becomes the repository for the process and PDK specification. OPS is the repository for the process documentation in a standardized format. When the process recording tools of the process engineer write OPS, the circuit designer can get the process information directly from the repository and other downstream processes can both read and write to the repository. The data is interpreted by the appropriate tools for both the process specification engine and the PDK generation engine with a common understanding. The engineers can use the best tool for visualizing the process, still using spread sheets or entering the process data directly into new domain specific editors.

The OpenPcell (OPL) definitions contain the operational parameters and the PDK specific values for the device. The implementation code is separate from the XML definition as the markup language does a poor job of representing code, especially in a language that is sensitive to beginning white space like Python. Some function calls or language specific code blocks can be included where necessary but the pcell definition is essentially language neutral.

The pcells can be generated to support the targeted design flows. For a homogeneous design flow, the code base would use single legacy language implementation. Heterogeneous environments including multi-vendor design tools, are supported using optimized implementation languages or be translated from the OPL Common Language Grammar (CLG) into tool specific pcells. The PDK generation engine can pick the implementation for the output PDK. For pcells written in the CLG, the CLG code is handed to an additional translator, which parses the syntax tree and generates output in the language of the PDK. James Masters of Intel has prototyped PyXlate to translate a restricted Python source file into GNU Common Lisp, a close relative of SKILL. IBM has donated an initial target device and Synopsys has donated their PyCell API definitions to demonstrate the functionality requirements for the language

The PDK generation engine reads the data from the repository and, with the use of plugins, generates the output necessary to run a set of design tools using the PDK. For verification tools, the outputs are decks in the appropriate language, which are vendor-specific. Models are populated with PDK specific information and their operational parameters are hooked to the devices through the DDF, created on the design tool as a CDF, I-CDF or other data driven parameter definition. Pcells are generated, either as a single language or to support multiple design flows. The PDK is then packaged and ready for testing.

Every version of the PDK must be validated before it is shipped to the customer. Validation should consist of more than physical and logical DRC, LVS and XOR’s; rule decks must be checked to assure they capture errors and model must be validated against measured results. The verification framework runs tests from various sources. The testing engines test the output of the PDK data against the “golden” process data, which they access from the OPS repository. EDA vendors already have engines that check for missing rules required by tools and generate data for testing decks. The PDKs can be tested in design flows using replay files from the design tools.

Effect on PDK Quality
There are many sources of the errors found in PDK’s. After inadequate understanding of the design flow requirements for the PDK, the transfer of data between tools creates the potential for errors at each translation. Data gets lost or is located in a non-standard format, which orphans it from the PDK flow. There is limited connection between the testing tools and the golden process definition contained in the DRM, if the DRM format can be read by outside tools.

OPS connects the Process Capture engines to the PDK Generation engines to the PDK Verification engines with a common understanding of the data representation, that defines what layer definition looks like and where the tools encounter a layer. The standard definitions ensure the represented data is understood. There is only one source repository and a common understanding, the tools have the proper inputs and consistently generate the proper output for the design flow. You cannot test in quality but the tests can compare the results of the PDK directly to the original description in the DRM. The tests, defined in the DRM, can be applied to each PDK version, be it language versions, DRM versions or code changes. Additional testing checks the different implementations against each other so all the resulting data is the same.

The PDK Engine Market
Let’s face it—PDK generation tools are a loss leader for EDA vendors. PAS from Cadence, developed by DST Technologies, is a graphical PDK capture and PDK assembly system that had hit the limits of proprietary repository format and only reached a small market. CiraNova gave away PyCell Studio and access to their APIs. Internally developed solutions dominate and are hard to replace, often because of the proprietary repository but mostly because they are adequate for the job. These systems are some of the longest lived in the CAD world, I worked on the Three Week Library PDK assembly project at one client and it found me again when an engineer from Moscow was in the Austin office eight years later and recognized my name and had a bug (it was in code that had been added). Again, years later, when I was teaching at a spin-off in Europe, they seemed to know who I was from my code.

The OPS standard will not greatly change the market for the big EDA vendors; the total market for PDK engines is small but is broadened by the OPS standard. The standard opens the market for process capture tools, apps running on the engineer’s tablet in the fab outputting OPS or even Eclipse based editors for describing a device for example. Vendors can supply new ways of visualizing the process and turning that vision into a PDK by supplying plug-ins to support their design flow. Tools that have languished for lack of standards can be updated so more can benefit from their unique capabilities.

Tool vendors can supply PDK generator engines to create solutions like RF IC passive devices, panel assemblers or other model generators. These can be smaller EDA companies who can focus on a smaller target market.

Tool vendors will supply some additional testing engines to raise the quality of the PDK, which helps contain support costs for their tools when the problem is missing or incorrect data in the PDK. There will be a number of companies supplying verification engines for different aspects of a PDK, from checking the process models against silicon to generating deck test structures.

Someone could even use the electronic DRM to generate a human readable document, preferably in PDF as a paper copy would be pretty thick and heavy.

This does not change the need for CAD engineers to support the unique PDK development flows, supplementing quality PDKs from the fab with design specific rules, devices and pcells and delivering a PDK to the designer that perfectly fits the design flow.

The OPS Standard
The OPS standard ties Process Capture, PDK Generation and PDK Verification engines together through the XML DRM. The engineers, at each step, can choose the best tools to describe the process or generate the PDK and maintain its integrity. Single source eliminates translation errors and the verification engine can use the original source for comparison. The data are connected from the fab to the designer in an unbroken chain.

OPS standards exist and continue to be developed. The DDF standard, the oldest standard, will be updated to use the new OPS elements derived from other OPS standard. The OpenDFM standard describes checking operations that are mapped into tool specific decks for verification tools. The OpenPCell standards are being developed from the working group inputs. SI2 is presenting an OpenPCell workshop to elicit input from the industry at large for the OPL XML representation and the OPL common language grammar. The Workshop is at the Network Meeting Center TechMart in Santa Clara, CA. I hope to see you there.